Shared tile map with live updates

ABSTRACT

Systems, methods, and devices are disclosed for synchronizing a map within shared memory for a navigating autonomous vehicle. A map, defined by a geographical area around an autonomous vehicle navigating a route, can be received and stored in shared memory. The shared memory can be a specific physical block of RAM. Concurrent access to the map within the shared memory can be granted to downstream nodes on the autonomous vehicle as the autonomous vehicle navigates the route. This shares the map among many nodes while, at the same time, allowing updates to the map without blocking those nodes at any time.

TECHNICAL FIELD

The present technology pertains to maps within a shared memory, and morespecifically pertains to synchronizing a map within shared memory for anavigating autonomous vehicle.

BACKGROUND

An autonomous vehicle (AV) is a motorized vehicle that can navigatewithout a human driver. An exemplary autonomous vehicle includes aplurality of sensor systems, such as, but not limited to, a camerasensor system, a lidar sensor system, a radar sensor system, amongstothers, wherein the autonomous vehicle operates based upon sensorsignals output by the sensor systems. Specifically, the sensor signalsare provided to an internal computing system in communication with theplurality of sensor systems, wherein a processor executes instructionsbased upon the sensor signals to control a mechanical system of theautonomous vehicle, such as a vehicle propulsion system, a brakingsystem, or a steering system.

Autonomous vehicles can use maps in order to orient themselves andnavigate routes. One such map can be a tiled map, which is a 2D mapwhere each pixel is mapped to a certain geolocation and stores a certainvalue of that area. While the format of these tiles could be anythingfrom portable network graphics (PNG) to uncompressed binary largeobjects (BLOB), the typical internal representation of these tiles areflattened 2D arrays. This makes this type of map extremely useful forrequests for values at (x,y) location on the map, which can be used fora preliminary filtration of input data from sensors or for quickfact-checks (e.g., is location (x,y) a sidewalk or drivable area?).

However, this usefulness comes at a cost. A disadvantage of tiled mapsis their excessive usage of RAM and Disk I/O latency when loading tiles.Tiled maps work reasonably well as long as the number of nodes that needto read from the map is limited. If multiple services (e.g., multiplenodes) need to access to the map during navigation, for example,currently all the tiles are loaded within a process memory space foreach individual node. This means the tiled map is duplicated for eachdifferent service, and as a consequence a large amount of CPU/RAM iswasted in order to load and store duplicated tiled map data. Anotherlimitation is that tiles are stored as individual tiles, makinginter-tile queries inefficient. What is needed are new systems andmethods for addressing these shortcomings of tiled maps.

BRIEF DESCRIPTION OF THE DRAWINGS

The above-recited and other advantages and features of the presenttechnology will become apparent by reference to specific implementationsillustrated in the appended drawings. A person of ordinary skill in theart will understand that these drawings only show some examples of thepresent technology and would not limit the scope of the presenttechnology to these examples. Furthermore, the skilled artisan willappreciate the principles of the present technology as described andexplained with additional specificity and detail through the use of theaccompanying drawings in which:

FIG. 1 illustrates an example schematic diagram of an autonomous vehicleand network environment, in accordance with some embodiments;

FIG. 2 shows an example system for multiple nodes accessing sharedmemory for a navigating autonomous vehicle in accordance with someembodiments;

FIG. 3A shows an example method for multiple nodes accessing sharedmemory for a navigating autonomous vehicle in accordance with someembodiments;

FIG. 3B shows an example method for generating virtual tiles andupdating methods within the shared memory in accordance with someembodiments;

FIG. 4 shows an example visualization of virtual tile maps and updateareas for a navigating autonomous vehicle in accordance with someaspects of the present technology;

FIGS. 5A-5D shows an example rolling array or sliding window techniquethat can be utilized for a memory-wise and cpu-wise solution or anavigating autonomous vehicle in accordance with some aspects of thepresent technology; and

FIG. 6 shows an example of a system for implementing certain aspects ofthe present technology.

DETAILED DESCRIPTION

Various examples of the present technology are discussed in detailbelow. While specific implementations are discussed, it should beunderstood that this is done for illustration purposes only. A personskilled in the relevant art will recognize that other components andconfigurations may be used without parting from the spirit and scope ofthe present technology. In some instances, well-known structures anddevices are shown in block diagram form in order to facilitatedescribing one or more aspects. Further, it is to be understood thatfunctionality that is described as being carried out by certain systemcomponents may be performed by more or fewer components than shown.

The disclosed technology addresses the need in the art for reducingexcessive usage of RAM and Disk I/O latency when loading tiles.Typically, all the tiles within a tiled map are loaded within a processmemory space for each individual node that needs to access the tiled mapduring navigation. Tiled maps work reasonably well in this way as longas the number of nodes that need to read from the map is limited. But ifmultiple services (e.g., multiple nodes) need to access to the map,especially at the same time, then the duplication of the tiled map foreach service wastes a large amount of CPU/RAM in order to load and storeduplicated tiled map data. Another limitation is that tiles are storedas individual tiles within the tiled map, making inter-tile queriesinefficient. New systems and methods for addressing these shortcomingsof tiled maps are needed.

The solution involves systems, methods, and devices for synchronizing amap within shared memory. For example, maps, defined by a geographicalarea around an autonomous vehicle navigating a route, can be receivedand stored in shared memory, where the shared memory can be a specificphysical block of RAM. Concurrent access to the map within the sharedmemory can be granted to downstream nodes on the autonomous vehicle asthe autonomous vehicle navigates the route. This shares the map amongmany nodes while, at the same time, allowing updates to the map withoutblocking those nodes from reading the map at any time.

For example, FIG. 1 illustrates environment 100 that includes anautonomous vehicle 102 with shared memory system 140 in communicationwith a remote computing system 150.

The autonomous vehicle 102 can navigate about roadways without a humandriver based upon sensor signals output by sensor systems 104-106 of theautonomous vehicle 102. The autonomous vehicle 102 includes a pluralityof sensor systems 104-106 (a first sensor system 104 through an Nthsensor system 106). The sensor systems 104-106 are of different typesand are arranged about the autonomous vehicle 102. For example, thefirst sensor system 104 may be a camera sensor system and the Nth sensorsystem 106 may be a lidar sensor system. Other exemplary sensor systemsinclude radar sensor systems, global positioning system (GPS) sensorsystems, inertial measurement units (IMU), infrared sensor systems,laser sensor systems, sonar sensor systems, and the like.

The autonomous vehicle 102 further includes several mechanical systemsthat are used to effectuate appropriate motion of the autonomous vehicle102. For instance, the mechanical systems can include but are notlimited to, a vehicle propulsion system 130, a braking system 132, and asteering system 134. The vehicle propulsion system 130 may include anelectric motor, an internal combustion engine, or both. The brakingsystem 132 can include an engine brake, brake pads, actuators, and/orany other suitable componentry that is configured to assist indecelerating the autonomous vehicle 102. The steering system 134includes suitable componentry that is configured to control thedirection of movement of the autonomous vehicle 102 during navigation.

The autonomous vehicle 102 further includes a safety system 136 that caninclude various lights and signal indicators, parking brake, airbags,etc. The autonomous vehicle 102 further includes a cabin system 138 thatcan include cabin temperature control systems, in-cabin entertainmentsystems, etc.

The autonomous vehicle 102 further includes a shared memory service 140that can include a shared memory that stores one or more maps that theautonomous vehicle 102 uses to orient itself and/or navigate. Sharedmemory system can include, for example, a non-volatile memory device andcan be a hard disk or other types of computer readable media which canstore data that are accessible by multiple services and/or systems onthe autonomous vehicle 102, such as random access memories (RAMs),read-only memory (ROM), magnetic cassettes, flash memory cards, solidstate memory devices, digital versatile disks, cartridges, and/or somecombination of these devices. For example, in some embodiments, sharedmemory service 140 can share the same physical block of RAM among sensorsystems 104-106.

The autonomous vehicle 102 additionally comprises an autonomous vehicle(AV) AV internal computing system 110 that is in communication with thesensor systems 104-106 and the systems 130, 132, 134, 136, and 138. TheAV internal computing system 110 includes at least one processor and atleast one memory having computer-executable instructions that areexecuted by the processor. The computer-executable instructions can makeup one or more services responsible for controlling the autonomousvehicle 102, communicating with remote computing system 150, receivinginputs from passengers or human co-pilots, logging metrics regardingdata collected by sensor systems 104-106 and human co-pilots, etc.

The AV internal computing system 110 can include a control service 112that is configured to control operation of the vehicle propulsion system130, the braking system 132, the steering system 134, the safety system136, and the cabin system 138. The control service 112 receives sensorsignals from the sensor systems 104-106 as well communicates with otherservices of the AV internal computing system 110 to effectuate operationof the autonomous vehicle 102. In some embodiments, control service 112may carry out operations in concert with one or more other systems ofautonomous vehicle 102.

The AV internal computing system 110 can also include a constraintservice 114 to facilitate safe propulsion of the autonomous vehicle 102.The constraint service 114 includes instructions for activating aconstraint based on a rule-based restriction upon operation of theautonomous vehicle 102. For example, the constraint may be a restrictionupon navigation that is activated in accordance with protocolsconfigured to avoid occupying the same space as other objects, abide bytraffic laws, circumvent avoidance areas, etc. In some embodiments, theconstraint service can be part of the control service 112.

The AV internal computing system 110 can also include a communicationservice 116. The communication service 116 can include both software andhardware elements for transmitting and receiving signals from/to theremote computing system 150. The communication service 116 is configuredto transmit information wirelessly over a network, for example, throughan antenna array that provides personal cellular (long-term evolution(LTE), 3G, 5G, etc.) communication.

In some embodiments, one or more services of the AV internal computingsystem 110 are configured to send and receive communications to remotecomputing system 150 for such reasons as reporting data for training andevaluating machine learning algorithms, requesting assistance fromremote computing system 150 or a human operator via remote computingsystem 150, software service updates, ridesharing pickup and drop offinstructions, etc.

The AV internal computing system 110 can also include a latency service118. The latency service 118 can utilize timestamps on communications toand from the remote computing system 150 to determine if a communicationhas been received from the remote computing system 150 in time to beuseful. For example, when a service of the AV internal computing system110 requests feedback from remote computing system 150 on atime-sensitive process, the latency service 118 can determine if aresponse was timely received from remote computing system 150 asinformation can quickly become too stale to be actionable. When thelatency service 118 determines that a response has not been receivedwithin a threshold, the latency service 118 can enable other systems ofautonomous vehicle 102 or a passenger to make necessary decisions or toprovide the needed feedback.

The AV internal computing system 110 can also include a user interfaceservice 120 that can communicate with cabin system 138 in order toprovide information or receive information to a human co-pilot or humanpassenger. In some embodiments, a human co-pilot or human passenger maybe required to evaluate and override a constraint from constraintservice 114, or the human co-pilot or human passenger may wish toprovide an instruction to the autonomous vehicle 102 regardingdestinations, requested routes, or other requested operations.

As described above, the remote computing system 150 is configured tosend/receive a signal from the autonomous vehicle 102 regardingreporting data for training and evaluating machine learning algorithms,requesting assistance from remote computing system 150 or a humanoperator via the remote computing system 150, software service updates,rideshare pickup and drop off instructions, etc.

The remote computing system 150 includes an analysis service 152 that isconfigured to receive data from autonomous vehicle 102 and analyze thedata to train or evaluate machine learning algorithms for operating theautonomous vehicle 102. The analysis service 152 can also performanalysis pertaining to data associated with one or more errors orconstraints reported by autonomous vehicle 102.

The remote computing system 150 can also include a user interfaceservice 154 configured to present metrics, video, pictures, soundsreported from the autonomous vehicle 102 to an operator of remotecomputing system 150. User interface service 154 can further receiveinput instructions from an operator that can be sent to the autonomousvehicle 102.

The remote computing system 150 can also include an instruction service156 for sending instructions regarding the operation of the autonomousvehicle 102. For example, in response to an output of the analysisservice 152 or user interface service 154, instructions service 156 canprepare instructions to one or more services of the autonomous vehicle102 or a co-pilot or passenger of the autonomous vehicle 102.

The remote computing system 150 can also include a rideshare service 158configured to interact with ridesharing applications 170 operating on(potential) passenger computing devices. The rideshare service 158 canreceive requests to be picked up or dropped off from passengerridesharing application 170 and can dispatch autonomous vehicle 102 forthe trip. The rideshare service 158 can also act as an intermediarybetween the ridesharing application 170 and the autonomous vehicle 102wherein a passenger might provide instructions to the autonomous vehicle102 to go around an obstacle, change routes, honk the horn, etc.

FIG. 2 shows an example autonomous vehicle system for multiple nodesaccessing shared memory for a navigating autonomous vehicle inaccordance with some embodiments. In some embodiments, the autonomousvehicle can navigate about roadways without a human driver based uponsensor signals output by sensor systems and maps of the route and/orsurrounding area. The maps, for example, can be tiled maps, or2-dimensional maps where each pixel is mapped to a certain geolocationand stores a certain value of that area. For example, each pixel cancorrespond to an (x,y) location and a value/data at that location, suchas a value corresponding to drivable vs. undrivable areas, objects(traffic signs, traffic lights, etc.), etc.

In some embodiments, the autonomous vehicle may have multiple servicesthat rely on the tiled map, sometimes simultaneously, such as anautonomous vehicle using a micro-service architecture with independentprocesses that communicate with each other while the autonomous vehiclenavigates a route. System 200, for example, shows managing node 202 incommunication with various downstream nodes—node 204, node 206, and node208. The various downstream nodes can be independent processesassociated with sensors and/or a navigation service that operate on ashared memory managed by shared map service 210. Shared map service 210,for example, can store shared map 220 data that can be simultaneouslyand/or concurrently accessed by the downstream nodes. For example,shared map 220 can be a specific physical block of RAM that stores themap, which is then accessible by one or more of node 204, node 206,and/or node 208 at the same time.

Shared map 220, for example, can be a 2-D tile map that includes pixelsmapped to a certain geolocation. Each pixel can store data, such as acertain value, at that geolocation. The data can be data previouslycaptured by lidar sensor(s) 212, camera sensor(s) 214, or any othersensors or systems that collect data for map generation on theautonomous vehicle. As the autonomous vehicle navigates, downstreamnodes can concurrently access the shared map 220 by querying for pixelvalues within the tile map.

In system 200, for example, the downstream nodes can be independentprocesses related to sensors and navigation services that operate on thespecific physical block of RAM in shared memory (e.g., shared map 220).For example, node 204 is a lidar service that measures distance to atarget by illuminating the target with laser light and measuring thereflected light with lidar sensor(s) 212. Differences in laser returntimes and wavelengths can then be used to make digital 3-Drepresentations of the target. Node 208 can be a camera service thatcaptures visual images with camera sensor(s) 214. Any number ofdifferent sensors may be used that can gather information about thenavigating autonomous vehicle's route, surrounding environment, and/orproximate objects (cars, pedestrians, traffic cones, etc.) in otherembodiments.

In some embodiments, the downstream nodes can interoperate with eachother, such as by providing services that take the output from otherdownstream nodes as its input. In system 200, for example, node 206 is atracking service, such as an autonomous vehicle stack, that operates onthe data provided by lidar sensor(s) 212 (node 204) and/or camerasensor(s) 214 (node 208). Because node 206 supports the tracking servicethat relies on data captured by other nodes, the map each node operateson should be the same across all nodes simultaneously. Shared mapservice 210 solves any potential undefined or inconsistent data betweendifferent map versions with shared map 220, since the downstream nodescan operate on the specific physical block of RAM and concurrentlycommunicate with the autonomous vehicle stack (e.g., tracking service onnode 206).

As a result, system 200's shared map 220 does not suffer from excessiveusage of RAM and Disk I/O latency to load map tiles, since it is nolonger required to load individual maps for each downstream node. Inaddition, system 200 results in more accurate data collection, analysis,and application since map versioning does not need to be copied andsynchronized across all the nodes that access the map in order tooperate.

FIGS. 3A and 3B show example methods for multiple nodes accessing theshared memory, in accordance with some embodiments. In FIG. 3A, method300 starts by receiving (302) a map defined by a geographical areaaround an autonomous vehicle navigating a route, which will become a mapshared by multiple nodes at the same time. In some embodiments, theentire map may be too large for efficient map processing in amicro-service architecture, which relies on multiple nodes to handledifferent services (e.g., lidar service, camera service, etc.), and so asubset of the entire map can be received by and stored (304) in sharedmemory. In some embodiments, in the autonomous vehicle, the map isstored on the hard drive. The hard drive could be big enough to storethe entire map (like a city wide map [e.g., San Francisco map], or astate-wide map [e.g., California map]). In order to use the map, a nodeneeds to load data from HD to RAM. The amount of RAM available incomputers is much less than HD, hence the entire map stored on HD maynot be able to be loaded to RAM at once. Instead, segments of the entiremap (set of tiles, virtual tile) can be loaded. Shared memory can thusbe used for the instances where it is too expensive for each node toload the same tiles. The shared memory can be, for example, a specificphysical block of RAM.

Downstream nodes on the autonomous vehicle can be granted (306)concurrent access to the map within the shared memory as the autonomousvehicle navigates the route. In some circumstances, the map withinshared memory will need to be updated in order to reflect any changesdue to car movement. Since the shared map stores and exposes for usersonly a small segment around the current autonomous vehicle location ofan entire map, this means data in shared memory needs to be updatedfollowing the autonomous vehicle's change of location. Since anydownstream node (and any number of downstream nodes) can access the mapwithin the shared memory at a given time, a synchronization method isneeded that allows the downstream nodes continuous access, but ensuresthat the downstream nodes are reading from the same map version.

FIG. 3B illustrates one such example method for and updating methodswithin the shared memory in accordance with some embodiments. Sharing amap through shared memory (e.g., for example, a shared map cache)introduces challenges over systems where maps are stored in each node'sown cache. Method 310 optimizes the amount of working memory needed touse the same segment of the map between multiple nodes.

An autonomous vehicle software can work with two or more of virtualtiles during its navigation process. For example, method 310 uses both acurrent virtual tile and a buffer virtual tile so that as the currenttile is used during navigation, the buffer virtual tile is prepared inadvance to allow for seamless switching. Any number of virtual tiles maybe used, depending on the amount of RAM space and Disk I/O latency thatis allowable in autonomous vehicle navigation.

Specifically, a first virtual tile can be defined (312) within theshared memory based on the map of a current geographical area around theautonomous vehicle. The first virtual tile, such as virtual tile A 404shown in the example visualization of virtual tile maps illustrated inFIG. 4, can be a set of tiles 410 in a given or defined region that canbe treated as a regular tile, but which covers all the area that can bequeried by the navigation service (e.g., the AV stack) at a given time.

In some embodiments, a virtual tile can be represented as a 2D arraythat can be stored within shared memory as a flattened representation ofthe 2D array. This can be an implementation that can provide access tomap values for given (x,y) coordinates. Any well known method forstoring 2D arrays can be used.

Since the autonomous vehicle 402 is navigating and changes position overtime, in order to maintain the actuality of map data within a virtualtile, the virtual tile needs to move along with the autonomous vehicle's402 position. As a result, while the autonomous vehicle 402 operates onthe first virtual tile (e.g., virtual tile A 404) to navigate, at leasta second virtual tile can be buffered (314) within the shared memorybased on the map of another geographical area around the autonomousvehicle.

In an embodiment, this second virtual tile can be virtual tile B 406,which covers an area within autonomous vehicle's 402 direction of traveland/or planned route. This allows the system to keep virtual tile A 404exposed to readers while preparing virtual tile B 406 for its subsequentposition.

In some embodiments, rolling array or sliding window techniques can beutilized for a memory-wise and cpu-wise solution, such as that shown inFIGS. 5A-5C. In FIG. 5A, virtual tile 502 is comprised of multiple tiles510 and buffer 520. In the example embodiment shown, virtual tile 502includes 4×4 tiles 510 and a buffer of 1 tile 510 size. This can be theinitial state of the shared Map. mapBegin 530 can point to the first (0,0) element of the virtual tile 502, the upper left corner (e.g., tile(−2,−2) 510). In some embodiments, mapBegin 530 and the rest of thevariables can be the meta information required to define the boundariesof virtual tile 502 and buffer 520 within the 2D rolling array.

In some embodiments, the sliding window can be rolled UP/DOWN/LEFT/RIGHTone operation at a time. FIG. 5B shows that in order to move virtualtile 502 to the right, the vertical buffer 520 line can be used to load4 new tiles 510. Then the mapBegin 530 is updated to point to the newleft upper corner of new virtual tile 502 (e.g., tile (−1,−2) 510).

In FIG. 5C, virtual tile 502 is moved to the right one more time (e.g.,the operation is repeated). Vertical buffer line 520 is used to load 4tiles 510 (which, in the real world, would be to the right side of thevirtual tile 502) but in a 2D rolling array, tiles 510 are placed to thebuffer line 520 no matter where it is. Then mapBegin 530 is updated(e.g., tile (0,−2) 510). Moreover, tile (2,−2) 510 can wrap around totile (3,−2) 510; tile (2,−1) 510 can wrap around to tile (3,−1) 510;tile (2,0) 510 can wrap around to tile (3,0) 510; and tile (2,1) 510 canwrap around to tile (3,1) 510.

FIG. 5D shows virtual tile 502 after several move operations. mapBegin530 is updated to tile (−1,1) 510. Tile (1,3) 510 can wrap around totile (2,−3) 510; tile (1,4) 510 can wrap around to tile (2,4) 510; tile(1,1) 510 can wrap around to tile (2,1) 510; and tile (1,2) 510 can wraparound to tile (2,2) 510. Moreover, tile (2,2) 510 can wrap around totile (2,3) 510; tile (−1,2) 510 can wrap around to tile (−1,3) 510; tile(0,2) 510 can wrap around to tile (0,3) 510; and tile (1,2) 510 can wraparound to tile (1,3) 510.

Since the shared memory has stored data for all the tiles within thefirst virtual tile, there is no need to load or update those values forany tiles within a subsequent virtual tile that overlaps with the firstvirtual tile. For example, if the second virtual tile is bufferingbefore the autonomous vehicle 402 reaches it, then any given tile withinthe second virtual tile that is also located within the first virtualtile can be bypassed or skipped when uploaded to the shared memory.

This means that in some embodiments, the shared memory need only storedata for tiles that are within the first virtual tile and the secondvirtual tile (e.g., only tiles within the current virtual tile andbuffering virtual tile). If tiles within the second virtual tile arewithin an area within the future geographical area but outside thecurrent geographical area of the first virtual tile (316), then thosetiles are added (318) to the shared memory. If the tiles within thesecond virtual tile are within the current geographical area of thefirst virtual tile, then those tiles are bypassed from being uploaded tothe shared memory and/or reused (320) since those tiles have alreadybeen stored on the shared memory.

For example, in FIG. 4, tiles within common area 408 are bypassed fromuploads associated with virtual tile B 406 to the shared memory, sincethose tiles have already been stored in association with virtual tile A404. This means that when virtual tile B 406 is uploaded during a bufferprocess, then only those tiles within virtual tile B 406 and outsidecommon area 408 needs to be uploaded into the shared memory.

Conversely, any tiles within the second virtual tile that are outsidethe future geographical area (322) can be deleted (324) from sharedmemory when the system switches the current tile from virtual tile A 404to virtual tile B 406, again bypassing common area 408 since those tilescan be reused.

Since any downstream node (and any number of downstream nodes) canaccess the map within the shared memory at a given time, asynchronization method is needed that allows the downstream nodescontinuous access, but ensures that the downstream nodes are readingfrom the same virtual tile. In some embodiments, updates to the mapwithin the shared memory can be performed without explicitly blockingthe readers. In order to do so, a version number can be assigned to aspecific virtual tile (e.g., version no. 001). When the next virtualtile is created, a next version number (e.g., version no. 002) can beassigned to the updated version of the map. The writer can update themap within the shared memory independently of whether the downstreamnodes are reading the map. In other words, the writer can update the mapeven if one or more downstream nodes are currently reading the map. Forexample, this can be implemented by storing the data of two virtualtiles in shared memory, where one is currently used by readers and theother one is used for the next map update.

In order to avoid version confusion, the system can check whether theversion of the map has changed while being read. For example, if adownstream node initiates a read operation on version no. 001 of themap, the system can determine if there is a match (326) between versionnumbers at the end of the read operation. If the version of the mapremains as version no. 001, then the query is returned. However, if theversion of the map changes due to an update in between the initiationand end of the read operation (e.g., the version of the map changes toversion no. 002), then the query is retried (328) at a subsequent timeuntil the version numbers match.

In some embodiments, the system can atomically switch operations fromthe first virtual tile to the second virtual tile when the autonomousvehicle reaches a specific distance from an edge of the first virtualtile. In other words, once the autonomous vehicle 402 reaches the marginof the current virtual tile (330), the buffer virtual tile can thenbecome the current virtual tile and the next virtual tile can begin tobuffer another virtual tile (defined by the next future geographicalarea within autonomous vehicle's 402 navigation). It does so byatomically switching (332) operations from the first virtual tile to thesecond virtual tile. Any queries are then returned (334) based on thesecond virtual tile instead of the first virtual tile.

As described herein, one aspect of the present technology is thegathering and use of data available from various sources to improvequality and experience. The present disclosure contemplates that in someinstances, this gathered data may include personal information. Thepresent disclosure contemplates that the entities involved with suchpersonal information respect and value privacy policies and practices.

FIG. 6 shows an example of computing system 600, which can be forexample any computing device making up internal computing system 110,remote computing system 150, (potential) passenger device executingrideshare app 170, or any component thereof in which the components ofthe system are in communication with each other using connection 605.Connection 605 can be a physical connection via a bus, or a directconnection into processor 610, such as in a chipset architecture.Connection 605 can also be a virtual connection, networked connection,or logical connection.

In some embodiments, computing system 600 is a distributed system inwhich the functions described in this disclosure can be distributedwithin a datacenter, multiple data centers, a peer network, etc. In someembodiments, one or more of the described system components representsmany such components each performing some or all of the function forwhich the component is described. In some embodiments, the componentscan be physical or virtual devices.

Example system 600 includes at least one processing unit (CPU orprocessor) 610 and connection 605 that couples various system componentsincluding system memory 615, such as read-only memory (ROM) 620 andrandom access memory (RAM) 625 to processor 610. Computing system 600can include a cache of high-speed memory 612 connected directly with, inclose proximity to, or integrated as part of processor 610.

Processor 610 can include any general purpose processor and a hardwareservice or software service, such as services 632, 634, and 636 storedin storage device 630, configured to control processor 610 as well as aspecial-purpose processor where software instructions are incorporatedinto the actual processor design. Processor 610 may essentially be acompletely self-contained computing system, containing multiple cores orprocessors, a bus, memory controller, cache, etc. A multi-core processormay be symmetric or asymmetric.

To enable user interaction, computing system 600 includes an inputdevice 645, which can represent any number of input mechanisms, such asa microphone for speech, a touch-sensitive screen for gesture orgraphical input, keyboard, mouse, motion input, speech, etc. Computingsystem 600 can also include output device 635, which can be one or moreof a number of output mechanisms known to those of skill in the art. Insome instances, multimodal systems can enable a user to provide multipletypes of input/output to communicate with computing system 600.Computing system 600 can include communications interface 640, which cangenerally govern and manage the user input and system output. There isno restriction on operating on any particular hardware arrangement, andtherefore the basic features here may easily be substituted for improvedhardware or firmware arrangements as they are developed.

Storage device 630 can be a non-volatile memory device and can be a harddisk or other types of computer readable media which can store data thatare accessible by a computer, such as magnetic cassettes, flash memorycards, solid state memory devices, digital versatile disks, cartridges,random access memories (RAMs), read-only memory (ROM), and/or somecombination of these devices.

The storage device 630 can include software services, servers, services,etc., that when the code that defines such software is executed by theprocessor 610, it causes the system to perform a function. In someembodiments, a hardware service that performs a particular function caninclude the software component stored in a computer-readable medium inconnection with the necessary hardware components, such as processor610, connection 605, output device 635, etc., to carry out the function.

For clarity of explanation, in some instances, the present technologymay be presented as including individual functional blocks includingfunctional blocks comprising devices, device components, steps orroutines in a method embodied in software, or combinations of hardwareand software.

Any of the steps, operations, functions, or processes described hereinmay be performed or implemented by a combination of hardware andsoftware services or services, alone or in combination with otherdevices. In some embodiments, a service can be software that resides inmemory of a client device and/or one or more servers of a contentmanagement system and perform one or more functions when a processorexecutes the software associated with the service. In some embodiments,a service is a program or a collection of programs that carry out aspecific function. In some embodiments, a service can be considered aserver. The memory can be a non-transitory computer-readable medium.

In some embodiments, the computer-readable storage devices, mediums, andmemories can include a cable or wireless signal containing a bit streamand the like. However, when mentioned, non-transitory computer-readablestorage media expressly exclude media such as energy, carrier signals,electromagnetic waves, and signals per se.

Methods according to the above-described examples can be implementedusing computer-executable instructions that are stored or otherwiseavailable from computer-readable media. Such instructions can comprise,for example, instructions and data which cause or otherwise configure ageneral purpose computer, special purpose computer, or special purposeprocessing device to perform a certain function or group of functions.Portions of computer resources used can be accessible over a network.The executable computer instructions may be, for example, binaries,intermediate format instructions such as assembly language, firmware, orsource code. Examples of computer-readable media that may be used tostore instructions, information used, and/or information created duringmethods according to described examples include magnetic or opticaldisks, solid-state memory devices, flash memory, USB devices providedwith non-volatile memory, networked storage devices, and so on.

Devices implementing methods according to these disclosures can comprisehardware, firmware and/or software, and can take any of a variety ofform factors. Typical examples of such form factors include servers,laptops, smartphones, small form factor personal computers, personaldigital assistants, and so on. The functionality described herein alsocan be embodied in peripherals or add-in cards. Such functionality canalso be implemented on a circuit board among different chips ordifferent processes executing in a single device, by way of furtherexample.

The instructions, media for conveying such instructions, computingresources for executing them, and other structures for supporting suchcomputing resources are means for providing the functions described inthese disclosures.

Although a variety of examples and other information was used to explainaspects within the scope of the appended claims, no limitation of theclaims should be implied based on particular features or arrangements insuch examples, as one of ordinary skill would be able to use theseexamples to derive a wide variety of implementations. Further andalthough some subject matter may have been described in languagespecific to examples of structural features and/or method steps, it isto be understood that the subject matter defined in the appended claimsis not necessarily limited to these described features or acts. Forexample, such functionality can be distributed differently or performedin components other than those identified herein. Rather, the describedfeatures and steps are disclosed as examples of components of systemsand methods within the scope of the appended claims.

What is claimed is:
 1. A method comprising: receiving a map defined by ageographical area around an autonomous vehicle navigating a route;storing the map in shared memory, wherein the shared memory is aspecific physical block of RAM; and granting concurrent access to themap within the shared memory to downstream nodes on the autonomousvehicle as the autonomous vehicle navigates the route.
 2. The method ofclaim 1, wherein the downstream nodes are independent processesassociated with sensors and a navigation service that operate on thespecific physical block of RAM, and wherein the independent processescommunicate with each other while the autonomous vehicle navigates theroute.
 3. The method of claim 1, wherein the downstream nodes are one ormore of a lidar service, camera service, or tracking service thatoperate on the specific physical block of RAM and concurrentlycommunicate with an autonomous vehicle stack.
 4. The method of claim 1,the method further comprising: defining a first virtual tile within theshared memory based on the map of a current geographical area around theautonomous vehicle; and while the autonomous vehicle operates on thefirst virtual tile to navigate, buffering a second virtual tile withinthe shared memory based on the map of a next geographical area aroundthe autonomous vehicle by: adding, to the shared memory, first areaswithin the future geographical area but outside the current geographicalarea, and removing, from the shared memory, second areas outside of thefuture geographical area.
 5. The method of claim 4, the method furthercomprising: atomically switching operations from the first virtual tileto the second virtual tile when the autonomous vehicle reaches aspecific distance from an edge of the first virtual tile.
 6. The methodof claim 1, the method further comprising: assigning a first versionnumber to the map in shared memory; and assigning a second versionnumber to the map when writing an update to the map, wherein a writerupdates the map within the shared memory independently of whether thedownstream nodes are reading the map.
 7. The method of claim 6, wherein,based on a read operation by one or more of the downstream nodes beinginitiated on the first version number to the map, the method furthercomprises: returning a query from the one or more of the downstreamnodes when a version of the map is matched to the first version numberduring the read operation; and retrying the query at a subsequent timewhen a version of the map is not matched to the first version numberduring the read operation.
 8. A non-transitory computer readable mediumcomprising instructions, the instructions, when executed by a computingsystem, cause the computing system to: receive a map defined by ageographical area around an autonomous vehicle navigating a route; storethe map in shared memory, wherein the shared memory is a specificphysical block of RAM; and grant concurrent access to the map within theshared memory to downstream nodes on the autonomous vehicle as theautonomous vehicle navigates the route.
 9. The non-transitory computerreadable medium of claim 8, wherein the downstream nodes are independentprocesses associated with sensors and a navigation service that operateon the specific physical block of RAM, and wherein the independentprocesses communicate with each other while the autonomous vehiclenavigates the route.
 10. The non-transitory computer readable medium ofclaim 8, wherein the downstream nodes are one or more of a lidarservice, camera service, or tracking service that operate on thespecific physical block of RAM and concurrently communicate with anautonomous vehicle stack.
 11. The non-transitory computer readablemedium of claim 8, the instructions further causing the computing systemto: define a first virtual tile within the shared memory based on themap of a current geographical area around the autonomous vehicle; andwhile the autonomous vehicle operates on the first virtual tile tonavigate, buffer a second virtual tile within the shared memory based onthe map of a next geographical area around the autonomous vehicle by:adding, to the shared memory, first areas within the future geographicalarea but outside the current geographical area, and removing, from theshared memory, second areas outside of the future geographical area. 12.The non-transitory computer readable medium of claim 11, theinstructions further causing the computing system to: atomically switchoperations from the first virtual tile to the second virtual tile whenthe autonomous vehicle reaches a specific distance from an edge of thefirst virtual tile.
 13. The non-transitory computer readable medium ofclaim 8, the instructions further causing the computing system to:assign a first version number to the map in shared memory; and assign asecond version number to the map when writing an update to the map,wherein a writer updates the map within the shared memory independentlyof whether the downstream nodes are reading the map.
 14. Thenon-transitory computer readable medium of claim 13, wherein, based on aread operation by one or more of the downstream nodes being initiated onthe first version number to the map, the instructions further cause thecomputing system to: return a query from the one or more of thedownstream nodes when a version of the map is matched to the firstversion number during the read operation; and retry the query at asubsequent time when a version of the map is not matched to the firstversion number during the read operation.
 15. A system comprising:downstream nodes on an autonomous vehicle; and a node in communicationwith the downstream nodes, the node comprising a service to: receive amap defined by a geographical area around the autonomous vehiclenavigating a route; store the map in shared memory, wherein the sharedmemory is a specific physical block of RAM; and grant concurrent accessto the map within the shared memory to the downstream nodes on theautonomous vehicle as the autonomous vehicle navigates the route. 16.The system of claim 15, wherein the downstream nodes are independentprocesses associated with sensors and a navigation service that operateon the specific physical block of RAM, and wherein the independentprocesses communicate with each other while the autonomous vehiclenavigates the route.
 17. The system of claim 15, wherein the downstreamnodes are one or more of a lidar service, camera service, or trackingservice that operate on the specific physical block of RAM andconcurrently communicate with an autonomous vehicle stack.
 18. Thesystem of claim 15, the node further comprising the service to: define afirst virtual tile within the shared memory based on the map of acurrent geographical area around the autonomous vehicle; and while theautonomous vehicle operates on the first virtual tile to navigate,buffer a second virtual tile within the shared memory based on the mapof a future geographical area around the autonomous vehicle by: adding,to the shared memory, first areas within the future geographical areabut outside the current geographical area, and removing, from the sharedmemory, second areas outside of the future geographical area.
 19. Thesystem of claim 18, the node further comprising the service to:atomically switch operations from the first virtual tile to the secondvirtual tile when the autonomous vehicle reaches a specific distancefrom an edge of the first virtual tile.
 20. The system of claim 15, thenode further comprising the service to: assign a first version number tothe map in shared memory; and assign a second version number to the mapwhen writing an update to the map, wherein a writer updates the mapwithin the shared memory independently of whether the downstream nodesare reading the map.